Hi, I'm going through Brian Komars book (and looking at other posts from this forum). i'm working on a 2 tier standalone offline root (workgroup) with a enterprise subordinate. 2008r2. On P.105 "the typical strategy for root CAs is to not publish CA and CRL retrievel URLs in the root CA's certificate." - so I figured i'd follow this strategy. I have therefore removed the AuthorityInformationAccess and CRLDistributionPoint sections from CAPolicy.inf. I have a few questions at the moment, becuase I am a little confused - all these relate to the offline root configuration only: 1. In the [certsev_server] section, there would be no point in putting the CRLxxxPeriodxxx lines. They would only be required if I wanted CRLs. Is this right? 2. In the post-install script, I also imagine I wouldnt need any of the certutil setreg CA\CRLxxxPeriodxxx lines either. A lot of examples have this on the root ca post-install script (even when the AuthorityInformationAccess and CRLDistributionPoint sections are missing from their CAPoliny.inf). If I had these, I think it would turn on CRL when I renewed the root CA Cert???? 3. If my second tier subordinate issuing CA got comprimised, how would this work? The subordinate CA would be set up to publish its CRL but it wouldnt list its own cert as invalid would it? If I wanted to allow for this, would I need to go back and enable CRL publication on the Root CA? 4. A number of sources have the root CA publishing CRLs every 26 weeks. Is this a better approach? Thank you

After reading a bit more, Would I be right in stating that the post-install script run on the offline root CA setting a CRL/AIA is for all future certificates it creates, ie. for the sub-ordinate certificate? Because that would make sense. If this is this the case, what would happen when renewing the root certificate? Would a CRL be added to the new root cert or does it continue not having one due to the capolicy.inf not having those fields???? thanks

Brian's description about the Root CA certificate only affects the Root CA certificate it self and is not about not having a CRL/AIA for the Root CA. Having the AuthorityInformationAccess and CRLDistributionPoint sections in the capolicy.inf for your Root CA grants that the CA certificates it self does not include any CDP/AIA information. The ADCS default CDP/AIA settings for Root CA has changed in the latest versions of Windows Server making it not necessary to have the sections for the purpose described. Yes, the Root CA certificate is going to continue be CRL/AIA less after the renew. You need to configure CRL & AIA publishing on your Root CA (for alla issued certificates) as many applications requires CRL validation of the entire certificate chain. The validity period of the CRL is depending on your routines and how often you can/want to operate the Root CA to publish a CRL. Typical publishing intervals are 6 months or 1 year. /Hasain

Hi, I'm going through Brian Komars book (and looking at other posts from this forum). i'm working on a 2 tier standalone offline root (workgroup) with a enterprise subordinate. 2008r2. On P.105 "the typical strategy for root CAs is to not publish CA and CRL retrievel URLs in the root CA's certificate." - so I figured i'd follow this strategy. I have therefore removed the AuthorityInformationAccess and CRLDistributionPoint sections from CAPolicy.inf. I have a few questions at the moment, becuase I am a little confused - all these relate to the offline root configuration only: 1. In the [certsev_server] section, there would be no point in putting the CRLxxxPeriodxxx lines. They would only be required if I wanted CRLs. Is this right? 2. In the post-install script, I also imagine I wouldnt need any of the certutil setreg CA\CRLxxxPeriodxxx lines either. A lot of examples have this on the root ca post-install script (even when the AuthorityInformationAccess and CRLDistributionPoint sections are missing from their CAPoliny.inf). If I had these, I think it would turn on CRL when I renewed the root CA Cert???? 3. If my second tier subordinate issuing CA got comprimised, how would this work? The subordinate CA would be set up to publish its CRL but it wouldnt list its own cert as invalid would it? If I wanted to allow for this, would I need to go back and enable CRL publication on the Root CA? 4. A number of sources have the root CA publishing CRLs every 26 weeks. Is this a better approach? Thank you I think you will find all answers here: http://en-us.sysadmins.lv/Lists/Posts/Post.aspx?ID=36My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

Hi, I'm going through Brian Komars book (and looking at other posts from this forum). i'm working on a 2 tier standalone offline root (workgroup) with a enterprise subordinate. 2008r2. On P.105 "the typical strategy for root CAs is to not publish CA and CRL retrievel URLs in the root CA's certificate." - so I figured i'd follow this strategy. I have therefore removed the AuthorityInformationAccess and CRLDistributionPoint sections from CAPolicy.inf. I have a few questions at the moment, becuase I am a little confused - all these relate to the offline root configuration only: 1. In the [certsev_server] section, there would be no point in putting the CRLxxxPeriodxxx lines. They would only be required if I wanted CRLs. Is this right? 2. In the post-install script, I also imagine I wouldnt need any of the certutil setreg CA\CRLxxxPeriodxxx lines either. A lot of examples have this on the root ca post-install script (even when the AuthorityInformationAccess and CRLDistributionPoint sections are missing from their CAPoliny.inf). If I had these, I think it would turn on CRL when I renewed the root CA Cert???? 3. If my second tier subordinate issuing CA got comprimised, how would this work? The subordinate CA would be set up to publish its CRL but it wouldnt list its own cert as invalid would it? If I wanted to allow for this, would I need to go back and enable CRL publication on the Root CA? 4. A number of sources have the root CA publishing CRLs every 26 weeks. Is this a better approach? Thank you I think you will find all answers here: http://en-us.sysadmins.lv/Lists/Posts/Post.aspx?ID=36My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki